Adaptable workflow and communications system

ABSTRACT

A data driven workflow solution that normalizes business communications by systematically recording related business communications from disparate communications channels in a common format such that the related business communications are automatically integrated into the associated business processes and which flow solution is flexible for capturing additional data elements or to adapt to changing tasks associated with the business processes is disclosed.

CROSS-REFERENCE TO RELATED APPLICATIONS Priority Claim

This application claims benefit of Provisional Application Ser. No.60/469,932, entitled ADAPTABLE WORKFLOW AND COMMUNICATIONS SYSTEM, byinventors, James E. Davis, Balasubramaniam Ganesh, and Kenneth L.Holmes, filed May 12, 2003, the entire contents of which is herebyincorporated by reference as if fully set forth herein, under 35 U.S.C.§119(e).

FIELD OF THE INVENTION

The invention relates to business process tracking and automation, andmore specifically to a system that enables rapid adaptation to changingbusiness processes by tracking all related activities andcommunications. Such a system provides facilities to enable on-demandexecution of automation functions. Business communications can besystematically recorded in a common format regardless of whether theoriginal format is email, instant messaging, workflow applicationupdates, voice conference, or other technology formats. In addition, thesystem framework enables interaction with other workflow applicationsincluding customer relationship management (CRM), enterprise resourceplanning (ERP), and information technology (IT) ticketing systems.

BACKGROUND OF THE INVENTION

The acceptance of corporate instant messaging, the increasinglyoverwhelming volume of email, and the proliferation of enterpriseworkflow applications are making business communications more fragmentedand inefficient. While each workflow and communications vehicle hasadvantages for specific types of business activities, there is no systemthat tracks and manages all of the related tasks and communications in anormalized form. Although integrated communications channel managementhas been addressed in specific niche areas, such as inbound customercommunication to a call center, there is currently no holistic solutionfor managing disparate communications channels for any business process.

While there are many systems available to track work activitiesassociated with a wide range of business processes, many of thesesystems do not capture the true work that is performed since much of thework is performed outside of the system. A great deal of the workactivity typically involves communications between process participants,and since the communication is not consistently tracked, thecommunication needs to be entered into the system after the work hasbeen performed.

Additionally, the available workflow systems do not provide theflexibility to keep pace with the rate of business change. Many of thesesystems require programming and database changes in order to captureadditional data elements associated with a business process or to changewhat tasks are required to fulfill a specific type of service request.

Based on the foregoing, there is a need for a business tracking systemthat provides for systematically recording business communications fromdisparate communications channels in a common format such that businesscommunications is automatically integrated into the associated businessprocesses and for flexibility to capture additional data elements or toadapt to changing tasks associated with the business processes.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not by wayof limitation, in the figures of the accompanying drawings and in whichlike reference numerals refer to similar elements and in which:

FIG. 1 is a high level diagram illustrating a manner in which controldata drives a request interface and consequent fulfillment tasks thatare spawned, according to certain embodiments;

FIG. 2 is a simple high level conceptual diagram illustrating key objectclassifications in a Core Object model;

FIG. 3 illustrates sample attributes of the Core-Ticket object and theMessage object, according to certain embodiments;

FIG. 4 is a schematic illustration of the Messaging architecture thatprovides an integrated messaging framework for uniform messagingcapabilities, according to certain embodiments;

FIG. 5 illustrates the manner in which the Relationship objectfunctions, according to certain embodiments;

FIG. 6 illustrates a Core-Group table and the objects that theCore-Group table relates, according to certain embodiments;

FIG. 7 illustrates a Core-Other table 710 and the objects that theCore-Other table relates, according to certain embodiments;

FIG. 8 illustrates a Core-Assets table and the objects that theCore-Assets table relates, according to certain embodiments;

FIG. 9 illustrates a Core-Documents table and the objects that theCore-documents table relates, according to certain embodiments;

FIG. 10 illustrates a Core-People table and the objects that theCore-People table relates, according to certain embodiments;

FIG. 11 shows the relationship between Core objects, according tocertain embodiments;

FIG. 12 illustrates a composite view if different core objects that arerelated by relationship tables, according to certain embodiments;

FIG. 13 shows the worker user interface that presents the normalizedtask and communications data, according to certain embodiments;

FIG. 14 shows the detailed task interface that presents all of theattributes, messages and relationships associated with a single task,according to certain embodiments;

FIG. 15 is a schematic that illustrates the use of integrating tools andother terminal emulators, according to certain embodiments

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

A data driven workflow solution that normalizes business communicationsby systematically recording related business communications fromdisparate communications channels in a common format such that therelated business communications are automatically integrated into theassociated business processes and which flow solution is flexible forcapturing additional data elements or to adapt to changing tasksassociated with the business processes is described.

In the following description, for purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of the present invention. It will be apparent, however, toone skilled in the art that the present invention may be practicedwithout these specific details. In other instances, well-knownstructures and devices are shown in block diagram form in order to avoidunnecessarily obscuring the present invention.

Business process tracking and automation is made possible by a commonobject model and an associated unified user interface. The common objectmodel include key objects such as core objects that provide relationsships between other core objects and/or a standard sets of objects,relationship objects for defining the relationships between objects, andmessage objects for providing unified messaging. Such a common objectmodel not only provides a unified view of all related components withinthe model, but also provides a data driven work flow solution for thegiven business process and automation.

According to certain embodiments, a system is used for establishing acommon data model to track and manage all forms of service requests,tasks, data objects and related business communications. In order toprovide a data driven workflow solution, the system is designed toenable data updates to drive the following:

-   -   The information that is collected based on the type of service        requested;    -   The tasks, and related dependencies, that are created based on        the type of service that has been requested;    -   The information that needs to be collected for each specific        type of task;    -   The automation functions that should be executed based on        specific events;    -   The automation functions that should be available to the task        assignee based on the task type;    -   The validation criteria of any data element;    -   The notifications that should be sent based on specific events.

All system communications are normalized to a common structure thatincludes two high-level objects, a core object, and a message object.There are different types of core objects. The different types of coreobjects include:

1) Core-ticket object;

2) Core-group object;

3) Core-other object;

4) Core-assets object;

5) Core-documents object;

6) Core-people object.

The above different types of core objects are merely illustrative. Thedifferent types of core objects depend on the particular business needsof a project or company and thus may vary from implementation toimplementation. The present invention is not limited to any particulartype of core objects. The different core objects are described ingreater detail herein with reference to FIG. 2, FIG. 6, FIG. 7, FIG. 8,FIG. 9 and FIG. 10.

Core objects provide a framework for relationships between a standardset of objects. Core objects can also provide a framework forrelationships between other core objects. The standard set of objectscan include objects such as a Request object, Project object, Taskobject, and Approvals object. The standard set of objects is describedin greater detail with reference to FIG. 2. The above standard set ofobjects is merely illustrative. The standard set of objects depends onthe particular business needs of a project or company, and thus may varyfrom implementation to implementation. The present invention is notlimited to any particular standard set of objects.

Another key component for maintaining a stable data model is themechanism for establishing relationships between objects. Such amechanism is referred to herein as a relationship object. Therelationship object manages data-driven control over certain types ofobject relationships without the need for modifying existing datastructures. Relationships and relationship objects are described ingreater detail herein with reference to FIG. 3, FIG. 5, FIG. 11, FIG.12, and FIG. 14.

Yet another key system component is the mechanism that provides unifiedmessaging. Such a mechanism is referred to herein as a message object.The foundation for the unified messaging component is the standard setof objects that represent the common denominator of any form ofcommunications. Message objects are tied to a core object and can beinstantiated by any combination of communication channels includingemail, instant messages, voice mail, or work flow application entries.Unified messaging and message objects are described in greater detailherein with reference to FIG. 2, FIG. 4, FIG. 13 and FIG. 14.

The system's unique capabilities stem from its common object model formanaging communications and from its data-driven approach to managingbusiness process tracking and automation. The system provides the basisfor a common automation platform and unified user interface that cansignificantly increase user productivity and quality of collectedbusiness information.

Administration interfaces (user interfaces) allow authorized users tomodify the control data in such a system. Such an approach allows rapidadaptation to changing business processes without the need foradditional programming. The system is designed to maintain commonintuitive interfaces for users making requests or for working theensuing tasks.

The user interfaces of the system can be web-based, i.e., HTML-baseduser interfaces. The user interfaces of the system are based on fourprimary user roles:

-   -   Requester interface—The requester interface focuses on a        data-driven wizard interaction for maximum efficiency and ease        of use.    -   Worker interface—The worker interface is based on providing        embedded communications and tools to enable users to perform        much of their work within the context of the system. When work        is performed within the context of the system, the work is        simultaneously documented automatically as the work is being        performed, thus obviating the need to manually document the work        after the work is performed.    -   Management interface—The management interface is focused on        providing access to comprehensive business process metrics.    -   Administrator interfaces—The administrator interfaces include a        system administrator interface, a process administration        interface, and a departmental administrator interface. Such        administrator interfaces enable system, process, and        departmental control data to be managed by designated        administrative personnel.

According to certain embodiments, the worker interface is designedaround the normalized project, request, task, message, and relationshipobjects. The worker interface leverages the common object structures inorder to provide the user with a unified display. Such a unified displayenables a single interface for communications and invocation ofautomation facilities for any type of task

The system administrator interface enables the creation of businessrules using a form-based wizard. Such business rules implementevent-based data validation, system notification and automation.

The process administrator interface enables control data to be modifiedfor controlling the types of requests that will be presented, the dataelements that are required for submitting a particular type of request,and what tasks will be generated to fulfill that request.

The departmental administrator interface will allow control data to bemodified that determines what data elements are required for specifictypes of tasks, what individuals are members of which workgroups, andwhich users have authority to approve requests for a given department.

The application framework is illustrated in FIG. 1. FIG. 1 shows by wayof example, the manner in which control data drives the requestinterface and the fulfillment tasks that are consequently spawned. Theexample demonstrates the manner in which dynamic data drives theworkflow system. The requester is presented with a list of choices 104generated from a Request object 102. Once a specific service is selectedfrom list of choices 104, the system checks the data elements requiredfor the selected service in the Required Request Attributes object 106.A page 108 is dynamically generated from this data to solicit therequired data from the user. When the data is provided by the user, thedata values are captured in the Instantiated Request Attributes object110.

In addition to instantiating the attribute values for the request, tasksare instantiated in the Instantiated Tasks object 112 based on valuesspecified for the particular type of request in the Required FulfillmentTasks object 114. Task attributes are then collected using a similartechnique thus allowing a greater level of customization to take placeby using control data and dynamically created application pages, with noneed for additional programming or changing the underlying datastructures.

FIG. 2 illustrates key object classifications in a Core Object model,according to certain embodiments. Objects are used for logicaldescription of an entity such as a Ticket. FIG. 2 shows a core objectsuch as Core-Ticket Object 210 that provides for relationship betweenother objects such as Request table 202, Project table 204, Task table206 and Approvals table 208. An object will correspond to a table in arelational database, hence the terms Object and Tables are usedinterchangeably. Other examples of objects are Human ResourceApplication tables, Peoplesoft Application table, SAP Inventory Managertable, etc.

Each object is identified by an object ID. For example, the Core-Tickettable 210 is identified by a core-ticket ID, the Request table 202 isidentified by a Request ID, the Project table 204 is identified by aproject ID, etc. Further, each table (object) includes a plurality ofattributes. Attributes of the Project, Request, Task and ApprovalsTables (objects) may be change as needed. At a minimum, the tablescontain attributes corresponding to the Core Ticket table. There is aone-to-one relationship between each attribute in a given table to acorresponding attribute in the Core table.

There can be as many Tasks and Approval record entries in the CoreTicket Table. The message table 212 is an object that represents adistinct contribution to any type of a record in one or more tablesrelated to the Core Ticket table such as the Project, Request, Approvalor Task tables. There is a one-to-many relationship between a given coreobject and message object. For example, in FIG. 2, the given Core-tickettable can have many messages associated with it. The Messages tablecontains a list of all the messages that are generated in theapplication. The sources for Messages are Email, Instant Messageclients, Fax and Voice.

A Relationship object exists for every Core Object to enable a typed,many-to-many relationship with any other Core Object. The Relationshipobject is covered in greater detail herein with reference to FIG. 3,FIG. 5, FIG. 11, FIG. 12, and FIG. 14.

FIG. 3 illustrates sample attributes of the Core-Ticket object and theMessage object, according to certain embodiments. Core ticket table 302includes attributes such as attributes 306. Message table 304 includesattributes such as attributes 308. Message table 304 is related toCore-ticket table 302 because the core-ticket ID 310 appears in bothCore ticket table 302 and Message table 304. Such core attributes areconsistent across every instantiation of the related objects and Messageobject, regardless of whether the objects are created by the system'srequest interface, a real-time messaging interface, or an externalsystem API. For any external system, such as email or an externalworkflow application, a mapping table is used to map the externalsystem's data structures to the system's thread (records) and messageobject format.

FIG. 4 is a schematic illustration of the Messaging architecture thatprovides an integrated messaging framework for uniform messagingcapabilities, according to certain embodiments. In FIG. 4, incomingmessages 402 are system or manually generated information that is sentor updated directly into the system. Messages 402 can be from anymessage type such as message types 404 a-d. The incoming messages 402are used for an input or update flow process 406. The incoming messages402 are then sent through a pre-processing flow 408 (i.e., converted toan appropriate format). Examples of pre-processing include mailprocessing parsing 409 a, socket connections 409 b, 409 d, and voiceprocessing 409 c. The inbound messages 402 are stored in inbound messagetable 410. A flow process 412 for applying business rules 414 is appliedto the inbound messages 402 stored in message table 410. Sample resultsfrom applying business rules 414 to the inbound messages 402 are updates416 to existing requests/projects/tasks, creations 418 of newrequests/projects/tasks, storage 420 of the messages in the relevantmessage tables associated with the given core object. Further,notifications 422 a-care sent based on subscriptions.

The following are examples of message types:

-   -   1. An email can be sent to the system by a user in order to        create a new Request for obtaining a new piece of equipment. In        this example, the text of the Email body will be stored in the        Messages Table    -   2. A user may like to post a question on the system Console        related to the Project that he/she is working on.    -   3. A user may like to capture a conference call with respect to        a problem and store the conference call along with the        associated Task that was generated in the system to track the        problem. The conference call can be saved as a wave file and        then attached to the associated task.    -   4. A user may like to store all the Unix commands that were        issued in an SSH client to fix a hardware problem and then store        the issued commands along with a Task that was created in the        system to track the hardware problem.

For purposes of explanation, assume that a user reports a new problemvia email and the new problem needs to be tracked in the system. In sucha case, the business rules are designed to automatically generate a newTask from the email from the user. In another example, assume that auser sends a detailed description in the body of the email regarding aproblem that has already been logged and tracked in the system. In sucha case, the email body is parsed and stored in the Messages table with areference to the problem identified by a Task ID.

Further, a user can subscribe to a topic by selecting the appropriaterecord from the system Console. A topic can be a Project, Request orTask. Subscription to a topic indicates to the system that it mustinform the user of any new messages that have been posted to thatparticular topic. Generally, all the messages that are posted to aparticular topic (Project, Request or Task) will be displayed in theMessages window of the system Console. A user can reply to the messagesvia the console. The reply will be treated as an inbound message to thesystem.

The following table illustrates sample attributes of a ticket-coreobject. In other words, the core-ticket object refers to a table, in therelational database, called “Core Ticket” with the following attributes:

Column Attribute Type Description Core Ticket ID Integer Display ColumnString Column Name that needs to be displayed when the details of theTicket is exposed to a user such as in a query Title String AssigneeString Owner String Create Date Date/Time Last Update Date/Time ProjectID Integer Request ID Integer Task ID Task ID Ticket Type String CoreStatus String Describes the current condition of the Ticket. Forexample, if this were an entry for a related Task, the Ticket statuscould be ‘In progress’ Related Status String Describes the currentcondition of the related item. For example, if this were an entry for arelated Task, the Related Status could be ‘Need Approval’ Source StringDescribes the origin of the data - manual or system generated AssignedGroup String Priority Integer

FIG. 5 illustrates the manner in which the Relationship objectfunctions, according to certain embodiments. For purposes ofexplanation, assume that FIG. 5 shows the relationship between a Projectand its associated Tasks. The Project records are stored in a ProjectTable and the Tasks in a Task Table. The Core-Ticket Table is used torelate the Project and its corresponding Tasks by creating an entry inthe Core-Ticket Table for each Task record along with its Project ID's.The relationship must be implemented by storing the unique identifiersof the entries in the tables to be related, into a common table. Sincethe Project consists of 3 Tasks, there are 3 records in the Core-TicketTable with the same Project ID (PR0016). Thus, in FIG. 5, the objectsthat are to be related are project table 502 and task table 506. Thecommon table is core-ticket table 504. As an example, project id 508“PR0016” in project table 502 is related to the associated tasks 510shown in the task table 506 by entries in the core-ticket table 504,Thus, in core-ticket table 504, the task ID column 514 is populated withtask IDs TK001, TK0010, TK0020 that correspond to project ID PR0016 asshown in project ID column 516 in core-ticket table 504.

By abstracting the relationship information into its own object, thereis a level of insulation between the application logic and theunderlying data model. Such a method eliminates required changes to thecore data model when new objects, or new types of relationships, areintroduced. Such an approach to managing relationships is consistentwith the other aspects of the system that allow control data tocustomize the functionality provided by the system's applications.

FIG. 6 illustrates a Core-Group table 610 and the objects that theCore-Group table relates, according to certain embodiments. Core-Grouptable 610 contains relationship information between Human ResourcesSystem tables 602, LDAP based Directory system tables 604, Users table606 and Groups table 608. Each of the objects (tables) has at least onerecord in the Core-Groups Table. Attributes of the Human ResourcesSystem tables 602, LDAP based Directory system tables 604, Users table606 and Groups table 608 can be defined depending on the needs of thebusiness. At a minimum, such tables (objects) contain attributescorresponding to the Core-Groups table 610. Each table is identified bya unique system generated id. Relationships between the Human ResourcesSystem table 602, LDAP based Directory system table 604, Users table 606and Groups table 608 are provided by the Core Groups Table in a fashionas previously explained with reference to the Core-ticket example ofFIG. 5.

FIG. 7 illustrates a Core-Other table 710 and the objects that theCore-Other table relates, according to certain embodiments. Core-Othertable 710 contains relationship information between SLA Agreements table702, Contracts table 704, tasks table 706, and maintenance agreementstable 708. Each object has at least one record in the Core-Other Table.Attributes of the SLA Agreement table, Contracts table, Task andMaintenance Agreements will be defined as needed. At a minimum, theobjects contain attributes corresponding to the Core-Other table. Eachtable is identified by a unique system generated id. Relationshipsbetween the SLA Agreements, Contracts, Tasks and Maintenance agreementsobjects are provided by the Core-Other Table in a fashion as previouslyexplained with reference to the Core-ticket example of FIG. 5.

FIG. 8 illustrates a Core-Assets table 810 and the objects that theCore-Assets table relates, according to certain embodiments. Core-Assetstable 810 contains relationship information between main asset table802, Purchasing System asset table 804, Asset Scanning Systems table806, and SAP/PeopleSoft/Oracle Financial Applications/or other systemstables that maintain Inventory information 808. The Relationships aremaintained by ‘Main asset ID’, ‘Purchasing System ID’, ‘Scan ID’ and‘Asset ID’. Each object has at least one record in the Core-AssetsTable. Attributes of the Main assets table, Purchasing System table,Asset Scanning Systems table, and SAP/PeopleSoft/Oracle FinancialApplications/or other systems tables can defined based on the businessneeds at hand. At a minimum, the tables contain attributes correspondingto those in the Core-Assets table. Each table is identified by a uniquesystem generated id. Relationships between the main assets table,Purchasing System table, Asset Scanning Systems table,SAP/PeopleSoft/Oracle Financial Applications/or other systems tables areprovided by the Core Assets Table in a fashion as previously explainedwith reference to the Core-ticket example of FIG. 5.

FIG. 9 illustrates a Core-Documents table 910 and the objects that theCore-documents table relates, according to certain embodiments.Core-documents table 910 contains relationship information between Filestable 902, Images table 904 and other Documents objects 906, 908 such asfaxes, manuals, etc. Relationship is maintained by ‘File ID’, ‘ImageID’, etc. Each object has at least one record in the Core-DocumentsTable. Attributes of the Files and Images Table can be defined based onthe business needs at hand. At a minimum, the tables contain attributescorresponding to those in the Core Documents table. Each table isidentified by a unique system generated id. Relationships between theFiles table, Images table, etc are provided by the Core-Documents Tablein a fashion as previously explained with reference to the Core-ticketexample of FIG. 5.

FIG. 10 illustrates a Core-People table 1010 and the objects that theCore-People table relates, according to certain embodiments. Core-Peopletable 1010 contains relationship information between Employees table1002, Customers table 1004, Vendors table 1006 and Skills table 1008.Relationship is maintained by ‘Employee ID’, ‘Customer ID’, ‘Vendor ID’and ‘Skill ID’. Each object has at least one record in the Core-PeopleTable. Attributes of the Employees, Customers, Vendors and Skills Tablescan be defined based on the business needs at hand. At a minimum, thetables contain attributes corresponding to those in the Core-Peopletable. Each table is identified by a unique system generated id.Relationships between the Employees, Customers, Vendors and Skillsobjects are provided by the Core-People Table in a fashion as previouslyexplained with reference to the Core-ticket example of FIG. 5

It may be necessary to relate Core tables so that related informationcan be presented to the end user. For purposes of explanation, assumethat a user may be interested in finding all the ‘Assets’ such asHardware, Software, etc., that are related to a given Ticket. This canbe achieved by providing a relationship between the Core-Ticket Tableand the Core Assets table. FIG. 11 shows the relationship between Coreobjects, such as Core Ticket table 1102 and the Core Assets table 1104.In FIG. 11, such a relationship is shown in the relationship table 1106.Relationship table 1106 contains the Core Ticket ID 1112 and thecorresponding Core Assets ID 1114. Core Ticket ID 1112 is the same asCore Ticket ID 1108. Similarly, Core Assets ID 1114 is the same as CoreAssets ID 1110. The relationship table 1106 has a many-to-manyrelationship with the Core Ticket table 1102 and Core Asset Table 1104.The same concept can be applied in order to provide relationshipsbetween other Core tables (objects).

FIG. 12 illustrates a composite view if different core objects that arerelated by relationship tables. FIG. 12 shows a core-people table 1202,a core-documents table 1204, a core-assets table 1206, a core-othertable 1208, a core-ticket table 1212, and a core-group table 1216.Relationship table 1210 contains relationship information that relatescore-people table 1202 and core-other table 1208. Similarly,relationship table 1214 contains relationship information that relatescore-documents table 1204 and core-ticket table 1212. Relationship table1218 contains relationship information that relates core-assets table1206 and core-group table 1216.

Integration of Tools such as MindTerm and other Unix Terminal Emulators

MindTerm is a software tool that allows for a SSH Session (Secure ShellSession) via an Applet. A SSH client is also referred to as awork-assist tool. This is similar to running exceed or SecureCRTterminal emulation software. According to certain embodiments, thesystem provides the ability of invoking MindTerm and other suchemulators from within the System such that the associated interactionssuch as commands that are issued via the Terminal sessions logged in aMessages Table. The MindTerm tool can be launched from the ‘Relatedwindow’ of the system Console, as illustrated in FIG. 14 herein.

The information that is stored in the Messages Table can then bedisplayed on the Messages Window as shown in FIG. 14 herein. There arevarious options that can be specified for the interaction with MindTermsuch as the ability to specify the option for capturing user issuedcommands, output from the command and specifying the number of thecommands that can be captured.

The following steps comprise the process flow capturing information whenusing integration tools.

-   -   1. A user invokes the system Console.    -   2. The user selects the tab called ‘Tools’ in the ‘Related        Details’ section of the console.    -   3. The user then selects an option to invoke the Mind Term        applet similar to a Unix Terminal window that can be used to        connect to other servers via SSH (Secure Shell). Secure shell is        a protocol that enables secure Terminal sessions.    -   4. The system the enables the capture of all the interaction        (both the command input and output) that are issued to the        server via the Terminal Session and store it in a database.    -   5. The information in the ‘Messages’ window of the console is        then refreshed after the Terminal Session is closed (or        destroyed) when the information is saved in the database.

For the Mindterm session, the operations information from the terminalsession can be saved in the 3 ways as described in item 1 of thePreferences Set-up below.

Preferences Set-Up:

-   -   1. The User may set an option where he/she might want to:        -   a. Simply capture the last 30 lines, for example <or any            number of lines and is configurable via preference settings            on the Server> from the session instead of capturing all the            commands.        -   b. Alternatively—the user may want to only highlight the            commands—similar to ‘Cut and Paste’ to save the specific            commands.        -   c. Saving all the commands from the session.    -   2. The ‘Messages’ window is dockable/undockable—i.e., the user        has the capability to expand the Window by undocking it to cover        the entire screen.

FIG. 15 is a schematic that illustrates the use of integrating tools andother terminal emulators, according to certain embodiments. FIG. 15shows the system console 1502, a remote machine such as a Unix server1504, application servers 1514, relational database 1516 and messagetable 1518. A user invokes a web browser and uses a terminal page 1508to establish a terminal session on remote Unix server 1504 using SSHconnections. The applet has a submenu 1510 for capturing and savinginformation (both command input an output) associated with the terminalsession. Such information can be stored in relational database 1516. TheMindTerm terminal applet page 1508 will be launched from a Java Serverpage The MindTerm session that is captured will be routed to theApplication server 1514 which in turn will route it to the relationaldatabase that it is connected to for eventual storage of the data in theMessage table 1516

System Administration Components

There are several system administration components in this softwaresystem, including key subsystems for application generation, businessrule generation, and normalizing external data. These components aredetailed in the following sections.

Application Generator

An application generation facility is provided for creating all of thefiles required to produce database, web application server and internetbrowser based client components. The application generator enables allof the technical components to be created without conventional coding,but rather through a form-driven specification of the attributes thatare desired for each particular application. The application generatorwill provide a facility to deploy applications that can be accessed viathe Internet using a Web browser.

Business Rule Generator

A software system facility enables the creation of application logic inthe form of business rules. The facility provides an interface to createthe control data that enables event based data validation, notification,and automation. The business rules can be created using a form which canfacilitate the construction of SQL statements (SQL) to retrieve and usedata from a relational database such as Oracle, Sybase, Informix, MySQL,MSSQL and DB2.

The SQL statements can be created by using higher level constructs thatcan automatically construct the SQL statements. The SQL statements willthen be automatically invoked by the system during run time in order toenforce the business rules.

Business Rules are constructed so that they can retrieve data fromanother system or update data in another database table.

Personal Business Rules

Personal Business Rules are business rules that apply only to anindividual user of the System. The system will allow an individual tocreate rules that can only be invoked for the conditions that the userhas set for himself or herself. An example of a rule that can be set isas follows:

“Notify me (user) whenever a trouble ticket is opened for a customer bythe name of XYZ.”

If this personal business rule is to be executed, the system notifies(i.e., sends an email, for instance) whenever a Trouble Ticket (or atask) is created in the system for Customer XYZ.

Adapters

For every external workflow application, communications channel, or datasource that will participate in the software system's data model, anadapter will provide the requisite access methods and attribute mappingformulas. For external workflow applications and communicationschannels, the external system's objects are mapped to this softwaresystem's common object model, in particular the Core-Ticket and Messageobjects. External data objects, such as ERP and CRM applications(Peoplesoft, Siebel, Oracle, SAP), will be mapped to a Proxy object inthis software system.

Worker Interface Components

To address the user interface requirements for the system for users whoare responsible for working tasks, UI components are provided by thesystem for real time messaging, searching for request and task data,updating object attributes, accessing related data and invokingautomation functions.

Message Console

The Message Console UI provides a single interface to view all messagesfor all threads contained in the system. FIG. 13 shows the primarysub-windows of the Message Console, including:

-   -   Folders 1302—This area is used to enable the user to navigate        the software system. Some of the functions that are made        available for the user include searching and submitting request        and task objects, system administration settings and report        selection. Folders section 1302 includes core threads folder        1302 a, Owning Group folder 1302 b, data folder 1302 c, and        system folder 1302 d.    -   Core-Ticket 1304 (Grid)—A grid shows the records (requests,        tasks, projects, change requests etc. . . . ) that were returned        based on the selected folder.    -   Messages 1308—This sub-window shows the messages 1308 a through        1308 d that are related to either all of the threads contained        in the thread grid or only those messages for the selected        individual thread. All messages are pushed from the server and        received by the user interface in real-time; therefore, no        manual or automatic pull/polling mechanism is required to view        new messages. The messages are ‘pushed’ to the Web browser by        using an applet that maintains a socket connection with the        client (the HTML Web browser).    -   Add Message 1310—This sub-window provides an input area 1310 a        to contribute a new message for an existing thread in real-time.    -   Fields 1306—This sub-window shows the attributes 1306 a through        1306 i for the selected thread.

Project/Request/Task/Approval Detail Forms

FIG. 14 depicts an example of a detail form. The Fields 1406, Messages1408 and Add Message 1410 sub-windows that were described with referenceto FIG. 13 above are also made available on the Detail Form for anindividual Project/Request/Task/Approval record. There is also a RelatedDetails 1412 sub-window that provides the user with access to allrelated tools, objects and audit logs that are available in this system.

The system provides a way to use these UI components for a variety ofcustom forms based on the type of request or task. While the forms arecustomized for specific tasks, there is still a consistent set of taskattributes that are collected for each type of task that enables alltasks to participate in with common system services.

In the foregoing specification, the invention has been described withreference to specific embodiments thereof. It will, however, be evidentthat various modifications and changes may be made thereto withoutdeparting from the broader spirit and scope of the invention. Thespecification and drawings are, accordingly, to be regarded in anillustrative rather than a restrictive sense.

1. A method for managing projects, requests, tasks, approvals andassociated communications regardless of source of said projects, saidrequests, said tasks, said approvals, the method comprising thecomputer-implemented act of: automatically building a flexibledynamically changeable business process tracking system for trackingsaid projects, said requests, said tasks, said approvals and saidassociated communications from disparate sources based on implementinglogical relationships between data associated with said projects, saidrequests, said tasks, said approvals and said associated communications,wherein the logical relationships are associated with one or morebusiness rules, wherein one or more workflow processes associated withthe business process tracking system are automatically generated inresponse to generation of at least a subset of the data, and wherein theflexible dynamically changeable business process tracking systemdynamically adapts to changes in control data.
 2. The method of claim 1,wherein said data comprises: a first plurality of sets of dataassociated with user defined services; a second plurality of sets ofdata that manages relationships between at least a subset of the firstplurality of sets of data; and communications data.
 3. The method ofclaim 2, wherein respective records associated with said first pluralityof sets of data and said communications data are instantiated by anycombination of communications channels, including at least one of email,instant messaging, voice, and workflow application entries.
 4. Themethod of claim 2, further comprising the act of: using an automationfacility that is associated with said services and said data; whereinsaid automation facility develops an application logic that isimplemented by using a form-driven administration interface; and whereinsaid automation facility automatically creates said one or more businessrules based on said application logic.
 5. The method of claim 2, furthercomprising the act of: using a common user interface that is associatedwith said data, wherein said common user interface is adapted forpresenting a unified view of at least a subset of said projects, saidrequests, said tasks, said approvals using a GUI window with associatedsub-windows.
 6. The method of claim 5, wherein said common userinterface is HTML web-based.
 7. The method of claim 1, furthercomprising the act of using a data-driven mechanism for describing andinstantiating said projects, said requests, said tasks, said approvalsand associated data elements.
 8. The method of claim 7, wherein saiddata-driven mechanism is adapted for one or more of: collecting a firstinformation based on said requests; creating said tasks and relateddependencies based on said requests; collecting a second informationbased on each of said tasks; driving one or more automation functionsbased on said tasks; validating said associated data elements; andsending notifications based on one or more events.
 9. The method ofclaim 2, wherein said first plurality of sets of data is of any typebased on business objectives.
 10. The method of claim 9, wherein saidany type includes at least one of: a ticket type; a group type; auser-defined type; an assets type; a documents type; and a people type;11. The method of claim 2, wherein said first plurality of sets of datais associated with a plurality of related data of any type based onbusiness objectives.
 12. The method of claim 11, wherein said any typeincludes at least one of: a request type; a project type; a task type;an approvals type; a human resources system type; an LDAP type; a userstype; a group type; an SLA agreements type; a contracts type; amaintenance agreement type; a main asset type; a purchasing system assettype; a scanning system type; an inventory system type; a files type; animages type; a fax type; a employee type; a customer type; a vendortype; and a skills type.
 13. The method of claim 1, further comprisingthe act of: using an integration mechanism for integrating input andoutput from integrating tools, work assist tools and terminal emulatorsinto said data.
 14. The method of claim 13, wherein the act ofintegrating includes: capturing input commands associated with usingsaid work assist tools and terminal emulators; capturing outputassociated with said input commands; storing said captured inputcommands and said captured output in associated communications data. 15.The method of claim 1, further comprising the act of: using asubscription mechanism for allowing end-users to subscribe to at least asubset of said communications data.
 16. (canceled)
 17. (canceled) 18.(canceled)
 19. (canceled)
 20. (canceled)
 21. (canceled)
 22. (canceled)23. (canceled)
 24. (canceled)
 25. (canceled)
 26. (canceled) 27.(canceled)
 28. (canceled)
 29. (canceled)
 30. (canceled)